Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ignore attempts to send to-device messages to bad users #17240

Merged
merged 2 commits into from
May 29, 2024

Conversation

erikjohnston
Copy link
Member

Currently sending a to-device message to a user ID with a dodgy destination is accepted, but then ends up spamming the logs when we try and send to the destination.

An alternative would be to reject the request, but I'm slightly nervous that could break things.

Currently sending a to-device message to a user ID with a dodgy
destination is accepted, but then ends up spamming the logs when we try
and send to the destination.

An alternative would be to reject the request, but I'm slightly nervous
that could break things.
@erikjohnston erikjohnston marked this pull request as ready for review May 28, 2024 15:51
@erikjohnston erikjohnston requested a review from a team as a code owner May 28, 2024 15:51
@reivilibre
Copy link
Contributor

nyurgh, it'd be nice to actually reject this at the source (400 Bad Request), at least for local users. (Over fed /send I suspect we just silently discard; failing the whole transaction sounds dangerous indeed).

Do we know which clients are emitting these?

I'm not in general a fan of just papering over issues, though I do understand why we have to be afraid here.

@erikjohnston
Copy link
Member Author

nyurgh, it'd be nice to actually reject this at the source (400 Bad Request), at least for local users. (Over fed /send I suspect we just silently discard; failing the whole transaction sounds dangerous indeed).

The main risk here is that since this is a batch send API failing due to one bad user may break encryption for all the other legitimate users. I think this is fairly unlikely to happen in practice, as mostly the batch sending is used for doing "all users in the room" or "all devices of a user", but I'm unwilling to make that bet right now.

(This doesn't apply over fed /send, as you'd only receive to-device messages for users on your own server, and so the server part must in fact be valid).

Do we know which clients are emitting these?

Unfortunately not. It mostly looks like the client(s) are not validating the user ID that people put into a text box (presumably create DM box), which isn't totally unreasonable and so I imagine this isn't limited to just one client.

@clokep
Copy link
Contributor

clokep commented May 29, 2024

It mostly looks like the client(s) are not validating the user ID that people put into a text box (presumably create DM box)

Can the create room be rejected? It won't catch old instances but should catch new ones.

@erikjohnston
Copy link
Member Author

It mostly looks like the client(s) are not validating the user ID that people put into a text box (presumably create DM box)

Can the create room be rejected? It won't catch old instances but should catch new ones.

it looks like we might send to-device messages before create room / invites maybe?

@erikjohnston erikjohnston merged commit d7198df into develop May 29, 2024
38 checks passed
@erikjohnston erikjohnston deleted the erikj/ignore_bad_user_ids branch May 29, 2024 10:52
erikjohnston added a commit that referenced this pull request May 30, 2024
We started ensuring we only insert valid destinations:
#17240
H-Shay pushed a commit to H-Shay/hq_synapse that referenced this pull request May 31, 2024
…7240)

Currently sending a to-device message to a user ID with a dodgy
destination is accepted, but then ends up spamming the logs when we try
and send to the destination.

An alternative would be to reject the request, but I'm slightly nervous
that could break things.
H-Shay pushed a commit to H-Shay/hq_synapse that referenced this pull request May 31, 2024
We started ensuring we only insert valid destinations:
element-hq#17240
Mic92 pushed a commit to Mic92/synapse that referenced this pull request Jun 14, 2024
…7240)

Currently sending a to-device message to a user ID with a dodgy
destination is accepted, but then ends up spamming the logs when we try
and send to the destination.

An alternative would be to reject the request, but I'm slightly nervous
that could break things.
Mic92 pushed a commit to Mic92/synapse that referenced this pull request Jun 14, 2024
We started ensuring we only insert valid destinations:
element-hq#17240
yingziwu added a commit to yingziwu/synapse that referenced this pull request Jun 26, 2024
- Fix the building of binary wheels for macOS by switching to macOS 12 CI runners. ([\#17319](element-hq/synapse#17319))

- When rolling back to a previous Synapse version and then forwards again to this release, don't require server operators to manually run SQL. ([\#17305](element-hq/synapse#17305), [\#17309](element-hq/synapse#17309))

- Use the release branch for sytest in release-branch PRs. ([\#17306](element-hq/synapse#17306))

- Fix bug where one-time-keys were not always included in `/sync` response when using workers. Introduced in v1.109.0rc1. ([\#17275](element-hq/synapse#17275))
- Fix bug where `/sync` could get stuck due to edge case in device lists handling. Introduced in v1.109.0rc1. ([\#17292](element-hq/synapse#17292))

- Add the ability to auto-accept invites on the behalf of users. See the [`auto_accept_invites`](https://element-hq.github.io/synapse/latest/usage/configuration/config_documentation.html#auto-accept-invites) config option for details. ([\#17147](element-hq/synapse#17147))
- Add experimental [MSC3575](matrix-org/matrix-spec-proposals#3575) Sliding Sync `/sync/e2ee` endpoint for to-device messages and device encryption info. ([\#17167](element-hq/synapse#17167))
- Support [MSC3916](matrix-org/matrix-spec-proposals#3916) by adding unstable media endpoints to `/_matrix/client`. ([\#17213](element-hq/synapse#17213))
- Add logging to tasks managed by the task scheduler, showing CPU and database usage. ([\#17219](element-hq/synapse#17219))

- Fix deduplicating of membership events to not create unused state groups. ([\#17164](element-hq/synapse#17164))
- Fix bug where duplicate events could be sent down sync when using workers that are overloaded. ([\#17215](element-hq/synapse#17215))
- Ignore attempts to send to-device messages to bad users, to avoid log spam when we try to connect to the bad server. ([\#17240](element-hq/synapse#17240))
- Fix handling of duplicate concurrent uploading of device one-time-keys. ([\#17241](element-hq/synapse#17241))
- Fix reporting of default tags to Sentry, such as worker name. Broke in v1.108.0. ([\#17251](element-hq/synapse#17251))
- Fix bug where typing updates would not be sent when using workers after a restart. ([\#17252](element-hq/synapse#17252))

- Update the LemonLDAP documentation to say that claims should be explicitly included in the returned `id_token`, as Synapse won't request them. ([\#17204](element-hq/synapse#17204))

- Improve DB usage when fetching related events. ([\#17083](element-hq/synapse#17083))
- Log exceptions when failing to auto-join new user according to the `auto_join_rooms` option. ([\#17176](element-hq/synapse#17176))
- Reduce work of calculating outbound device lists updates. ([\#17211](element-hq/synapse#17211))
- Improve performance of calculating device lists changes in `/sync`. ([\#17216](element-hq/synapse#17216))
- Move towards using `MultiWriterIdGenerator` everywhere. ([\#17226](element-hq/synapse#17226))
- Replaces all usages of `StreamIdGenerator` with `MultiWriterIdGenerator`. ([\#17229](element-hq/synapse#17229))
- Change the `allow_unsafe_locale` config option to also apply when setting up new databases. ([\#17238](element-hq/synapse#17238))
- Fix errors in logs about closing incorrect logging contexts when media gets rejected by a module. ([\#17239](element-hq/synapse#17239), [\#17246](element-hq/synapse#17246))
- Clean out invalid destinations from `device_federation_outbox` table. ([\#17242](element-hq/synapse#17242))
- Stop logging errors when receiving invalid User IDs in key querys requests. ([\#17250](element-hq/synapse#17250))

* Bump anyhow from 1.0.83 to 1.0.86. ([\#17220](element-hq/synapse#17220))
* Bump bcrypt from 4.1.2 to 4.1.3. ([\#17224](element-hq/synapse#17224))
* Bump lxml from 5.2.1 to 5.2.2. ([\#17261](element-hq/synapse#17261))
* Bump mypy-zope from 1.0.3 to 1.0.4. ([\#17262](element-hq/synapse#17262))
* Bump phonenumbers from 8.13.35 to 8.13.37. ([\#17235](element-hq/synapse#17235))
* Bump prometheus-client from 0.19.0 to 0.20.0. ([\#17233](element-hq/synapse#17233))
* Bump pyasn1 from 0.5.1 to 0.6.0. ([\#17223](element-hq/synapse#17223))
* Bump pyicu from 2.13 to 2.13.1. ([\#17236](element-hq/synapse#17236))
* Bump pyopenssl from 24.0.0 to 24.1.0. ([\#17234](element-hq/synapse#17234))
* Bump serde from 1.0.201 to 1.0.202. ([\#17221](element-hq/synapse#17221))
* Bump serde from 1.0.202 to 1.0.203. ([\#17232](element-hq/synapse#17232))
* Bump twine from 5.0.0 to 5.1.0. ([\#17225](element-hq/synapse#17225))
* Bump types-psycopg2 from 2.9.21.20240311 to 2.9.21.20240417. ([\#17222](element-hq/synapse#17222))
* Bump types-pyopenssl from 24.0.0.20240311 to 24.1.0.20240425. ([\#17260](element-hq/synapse#17260))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants